Exposing functions of legacy applications to enable the legacy applications to interact with other applications can lead to significant cost savings. Certain functions of the legacy applications can be re-defined as modular, self-contained services. The capabilities of these services may be independent of context or a state of other services. Additionally, these services may be designed to be invoked via a well-defined interface. These services may be enabled in a Service-oriented Architecture (SOA) through an Enterprise Service Bus (ESB), which connects and mediates communications and interactions between the services.
As interchange of information increases, there is an increased risk that sensitive information may be unintentionally disclosed to unintended parties. SOA architectures are generally designed to transmit all user messages across one or more networks. These SOA architectures may use sessions between users to transmit data or services over a network.
Certain ESB and SOA architectures are not secure. To address this concern, an ESB or SOA architecture may be secured by inspecting an entire data stream of communications using a high assurance data guard over an Internet Protocol (IP) network. The data guard acts as an intermediary between users of a service, performing “deep packet inspection” to examine contents of the data stream for any sensitive data and or service. For example, the data guard may receive a message via a service from a first user, inspect the contents of the message, and then either re-transmit the message to an intended receiver or block the message when the message is not authorized (e.g., blocking unauthorized distribution of sensitive information). In addition, it is difficult to secure an SOA or an Enterprise service bus (ESB) over disparate systems.
ESBs and SOAs may be limited by low bandwidth and high latency. The low bandwidth and high latency may hinder the ability of service applications to transmit data in real-time while simultaneously providing separation by security level. For example, bandwidth may be limited by a number of packets that the data guard can process; latency may be limited by a speed at which the data guard can inspect and process the data packets. Thus, a full SOA or ESB implementation may be limited in scale by the limited capabilities of the data guard.
Data transmitted during SOA sessions is transient. Thus, the data cannot be retrieved for later use or analysis. If a user is not able to receive a communication in real-time, the communication cannot later be retrieved unless a separate, parallel process records and distributes the communication.
Large-scale, distributed computing environments, such as those that may use a SOA or ESB, often accommodate heterogeneous hardware and software components, network links of varying latencies, and unpredictable hardware or software failures in the network or the computers. In large storage area network (SAN) or network attached storage (NAS) environments, hardware or software failures may result in abnormal termination of applications and corrupted data files. Duplicate hardware components may be deployed to address hardware and software failure concerns. The duplicate hardware may support continual copying of files, file systems and/or mirrored systems. Additionally, complex, expensive software may be used to manage local and remote file systems. Manual intervention may be used to re-construct files from checkpoints.